Electronic devices such as communication devices often incorporate hardware, software, and firmware which cooperate to support device functions. Common hardware components include processors such as Central Processing Units (CPUs), Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), and memory devices, for example. Firmware generally refers to low-level, executable code which controls basic functions of hardware, and may be stored in various types of memory device, including Erasable Programmable Read Only Memory (EPROM), Electrically Erasable PROM (EEPROM), Random Access Memory (RAM) for instance, or effectively embedded into the hardware devices it controls, as in the case of FPGAs and PLDs. Higher-level functions are normally supported in software. Software is normally stored in non-volatile memory, and loaded into volatile memory, illustratively RAM, for execution. Operating system code and software applications represent illustrative examples of software.
A hardware change may be necessary for an electronic device due to a specification change for a particular component, cost reduction reworking of the device, component obsolescence, etc. Hardware changes can present an operations and maintenance problem when a change also necessitates a software or firmware change. This situation may be particularly problematic where an electronic device is an electronic circuit card in communication equipment or part of some other widely deployed electronic system. An enterprise which operates many systems in which particular circuit cards are used and kept as spares may wish to standardize its systems to a given specific version of hardware, software, and firmware. For example, telecommunications service providers typically have this requirement, as do other organizations which require reliable communication or computing networks, including banks, utilities, hospitals, etc.
U.S. patent applications Ser. No. 10/252,703, entitled “SYSTEM AND METHOD FOR MANAGING CONFIGURABLE ELEMENTS OF DEVICES IN A NETWORK ELEMENT AND A NETWORK”, filed on Sep. 24, 2002, and published on Jul. 24, 2003 with Publication No. 2003/0140134, and Ser. No. 10/392,867, entitled “SYSTEM AND METHOD FOR TRACKING ENGINEERING CHANGES RELATING TO A CIRCUIT CARD”, filed on Mar. 21, 2003, and published on Sep. 23, 2004 with Publication No. 2004/0186690, describe systems and methods for tracking the compatibility of various versions of hardware, software, and firmware associated with an electronic device or a system of electronic devices.
According to the compatibility tracking mechanisms described in the above applications, software and firmware which are compatible with particular hardware are identified and loaded into an electronic device. In the event that compatible software and firmware are not available on the device, new software and firmware may be downloaded from a remote location. Thus, hardware changes which are not fully compatible with previous versions of software and firmware may result in new software and firmware loads.
One disadvantage of distributing separate software and firmware upgrade files for new hardware is that customers must then separately apply patches or new software and firmware, which increases the number of aspects of hardware upgrades which are managed by a customer. Separate software and firmware upgrades also complicate efforts to standardize software for use in all electronic devices operated by an enterprise. Releasing a new application load to customers who have standardized on a previous release, for instance, would involve the customer re-deploying a new load standard. This additional level of upgrade complexity may tend to make customers reluctant to upgrade hardware.
In addition, manufacturers typically cannot ship hardware until they ensure that it works with software. If a new application load is required for new hardware, then this dependence on software may create operations slow-downs until the new application load is qualified. For example, if a new application load is required for a cost reduction hardware change, then the hardware change could not normally be made until the majority of the customer base has moved to a minimum software version that supports the new hardware. This often takes several years after the first software load which supports the cost reduced hardware has been made available to customers.
There are also cases in which there would be significant cost associated with a customer moving to a new application load standard. Customers must often validate a new load before allowing it to be used on in-service equipment. Validation time can range widely, from no validation at all to several months or even a year of test coverage. This may make some customers very reluctant to take new loads without an associated business case, such as where a new load provides no new functionality and thus no new revenue potential.
According to other approaches, complex product numbering schemes are used to ensure that customers order a specific hardware product and matching software/firmware. Clearly, this would be complex to establish, deploy, and maintain. For example, where a cost reduction plan on a product A results in a new version product A2 which requires slightly different firmware, customers, including former purchasers of product A, would need to explicitly order product A2 and corresponding software/firmware A2.
Thus, there remains a need for improved techniques for managing electronic devices and their configuration, through software and/or firmware, for example.